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[57] ABSTRACT 

The present invention pertains to an apparatus a nd pro cess 
for storing information object collections in a database. 
Examples of such object collections are nested tables and 
variable length arrays. In an embodiment, the invention 
provides mechanisms and me t hodsJfo r s toring nested tabl es 
in either a base t able of a datab ase, or an index-orga nized 
Table. In one embodiment, mecnanisms and metRoHs are 
provided for storing variable length arrays into a table 
column, as a large object ("LOB"), or as an index-organized 
table. The invention also provides methods and mechanisms 
for accessing data from these storage mediums. 
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FIGURE 1 
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FIGURE 2 
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FIGURE 3 
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APPARATUS AND METHOD FOR STORAGE 
OF OBJECT COLLECTIONS IN A 
DATABASE SYSTEM 

FIELD OF THE INVENTION 

This invention generally relates to data processing, and 
relates more specifically to methods of storing collections of 
information as part of objects that are managed using a 
database system. 

BACKGROUND OF THE INVENTION 

Database systems are computer programs optimized for 
creating, storing, manipulating, and reporting on informa- 
tion stored in tables. Each table is organized as an array of 
rows and columns. The values in the columns of a given row 
are typically associated with each other in some way. For 
example, a row may store a complete data record relating to 
a sales transaction, a person, or a project. Columns of the 
table define discrete portions of the rows that have the same 
general data format. For example, columns define fields of 
the records. 

Many computer programming languages permit informa- 
tion to be defined by an object type, "class/' or "abstract data 
type" (ADT). ADTs provide a way to classify information. 
In computer programs written using a language that supports 
ADTs, every constant, variable, expression, function, or 
combination has a certain type. Thus, an ADT is an abstract 
representation of data that serves as a template for an 
information object. An ADT is made into an explicit repre- 
sentation of the type using a declaration of the constant, 
variable, or function. The thing that is declared is called an 
information object or simply an object. In object-oriented 
programming languages such as C++ and Java, the term 
"class" refers to the ADT of an object. Objects may store a 
combination of data and methods for acting on the data. An 
"instance" of an object matching a class is "instantiated" or 
created when the program is run, based upon the class 
definition of the object. 

A detailed discussion of ADTs and data structures is 
provided in N. Wirth, "Algorithms+Data Structures- 
Programs" (Englewood Cliflfe, N.J.: Prentice-Hall, 1976), 
and D. Knuth, "The Art of Computer Programming" 
(Reading, Mass., Addison- Wesley Pub. Co., 2d. ed. 1973), 
ch. 2, "Information Structures". In the context of this 
document, the term "ADT" refers broadly to a type defini- 
tion or object class for an information object and is intended 
to include the meaning of the term "class" as that term is 
used in object-oriented programming environments. 

ADTs may be complex. An ADT may comprise a com- 
bination of one or more scalar data types such as integers, 
arrays and other numeric types, characters or strings, 
pointers, other ADTs, database tables, or large arrays. Each 
component of an ADT is called an attribute. However, 
database systems are known to operate fastest and with 
greatest efficiency when simple data types are stored in the 
database tables. Accordingly, storing objects defined by 
complex ADTs in a database table presents a difficult prob- 
lem. A number of effective approaches to this problem are 
disclosed in co-pending U.S. patent application Ser. No. 
08/962,409, "Object Representation and Storage in a Data- 
base System," attorney docket number 3018-093 (OID 
1997-10-02), which is hereby incorporated by reference as 
if fully set forth herein. 

A related problem is communicating complex information 
objects in a complex, distributed system or network that 
interconnects different types of computers and program 
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processes. Data are not universally transportable from one 
computer to any other computer. Different computers, oper- 
ating systems, programming languages, and application 
software often use different native forms or formats for 

5 representing data. For example, several different formats can 
be used to represent numbers in a computer memory. Some 
processors represent a numeric value in memory as a string 
of bits in which the least significant bit is at the lowest 
memory location. Other processors represent values with the 

10 most significant bit at the lowest memory location. One type 
of processor cannot directly access and use values stored in 
a memory that were created by the other type of processor. 
This is known as a format representation problem. Examples 
of such incompatible processors are the SPARC and VAX 

15 processors. 

Incompatibilities also exist among different programming 
languages that are usable on the same platform. For 
example, such modern programming languages as C and 
Pascal enable a programmer to express a set of information 

2Q in a complex abstract data type such as a record or structure, 
but there is no universal protocol for representing such 
abstract data types in a computer memory. This incompat- 
ibility increases the complexity of computer systems and 
makes data interchange difficult and inefficient. Further, 

25 different processors may represent a data type of a program- 
ming language in different ways. One processor may rep- 
resent a floating-point number in four bytes while another 
processor may represent it in eight bytes. Thus, data created 
in memory by the same program running on different 

3Q processors is not necessarily interchangeable. This is known 
as a layout representation incompatibility. 

Alignment representation presents yet another problem in 
data interchange. With some processors, particular values or 
data types must be aligned at a particular memory location. 

35 When data is interchanged, there is no assurance that the 
inbound information uses the alignment required by the 
computer receiving the information. Still another problem is 
inheritance representation. Certain object-oriented program- 
ming languages, such as C++, support the concept of 

40 inheritance, whereby an abstract data type may inherit 
properties of a previously defined abstract data type. Lan- 
guages that support inheritance provide extra pointer fields 
in memory representations of abstract data types or classes 
that use base classes and functions defined at runtime. The 

45 value of an inheritance pointer is not known until runtime, 
and is not persistent. Therefore, transmission from one 
system to another of an instance of an abstract data type that 
inherits properties from another abstract data type is not 
generally practical. 

50 Character representation is another problem. Computers 
used in different nations of the world also may use incom- 
patible character sets. Data formatted in one character set 
cannot be directly used or interpreted by a system that uses 
a different character set. 

55 In a networked computer environment, these problems are 
more acute. A network may comprise several different types 
of computers, platforms, or application programs. A pro- 
grammer writing software for use in a widely distributed 
network has no assurance that a destination or target com- 

60 puter can understand information sent from a source 
machine. Moreover, many network communication proto- 
cols are best suited to the transmission of simple, linear 
strings of values or characters. Complex abstract data types, 
especially those with pointers, generally cannot be transmit- 

65 ted reliably over such a network in the same form used to 
represent the data types in memory. Also, when a pointer 
points to a large or complex collection of data values, such 
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as a table of a database system, it may be impractical or steps of establishing a collection attribu te in the information 

inefficient to convert the entire table to a universal form for o bject; establishing a first table of attiitjutes^oi the lnrtSrma- 

transmission over the network. ti bn object in the database system; establishing a collectio n 

Approaches to solving these problems are presented in the storage str uctu re for the collection attribute in the datab ase 

above-referenced copending U.S. Patent Application, and in 5 s ystem; storing a reference to the collection storage struc ture 

co-pending U.S. patent application Ser. No. 08/961,795, in~a column of uieflr st table; and" storing values of th e 

entitled "Apparatus and Method for Pickling Data," attorney collection attribute i n t he collecdon"storage structure. One 

docket number 3018-092 (OID 1997-10-01). feature ' 01 tW aspect of the invention is establishing a 

Still another problem encountered in these systems is the second table in the database system; and storing first and 

storage and internal representation of information objects 10 SCC ond identifiers of the first table and the collection storage 

that are defined by ADTs that have collection attributes. In structure in respective columns of the second table. Another 

this context, collection attribute refers to a non-scalar feamre involves establisrnng the colledion storage structure 

attribute comprising a related set of scalar attributes, m ^ form of a c ^ {n ^ databflSC 

arranged in one or two dimensions For example, collection establishi in the stor tabl at bast onc ncstcd tabk 

attributes include nested database tables and varying length A . & . . & r . fiL „ 4 . - A 

J & & 15 portion com rinsing rows of values of the co llec tion attribu te 

Yet another problem of these systems is the storage and ^iated with the reference ; a nd slonnp a copy .o f the 

representation to columns of tables managed by database reference in a base table identifier column of the storage 

systems, including relational databases and object-relational table. 

database systems, of information objects that are collections. Another feature is that the step of establishing a collection 

For example, present database systems do not provide a 20 attribute in the database system comprises the step of 

mechanism by which information collections, such as a establishing a variable length array as the collection attribute 

database table or a varying length array, can be stored in a of the information object. A related feature is that when the 

column of a database table. variable length array is defined having fixed -length ele- 

Present systems do not provide a convenient, efficient way ments: computing a maximum size value representing an 

to store information objects defined by an ADT in which 25 amount of storage space required for an instance of the 

attributes are collections. In one approach, when an appli- variable length array; and storing the variable length array in 

cation needs to have a collection associated with an infor- a database column when the maximum size value is equal to 

mation object, generally the collection has to be stored apart 0 r less than a pre-defined maximum database column size 

from the information object, e.g., in a separate object. In this va i ue . Another related feature is that the step of storing the 

approach, the system also must provide a mechanism to 30 variable length array in a large object structure when the 

relate the original information object to the collection object. m udmum size value is greater than the maximum database 

This is awkward and imposes ^overhead. Having memods for siz£ valu£ sm afl0ther related feature invol 

storing collections as attributes of an ADT is highly when the variabk fc fa ^ defined havin yariable . 

desirable, because it provides programmers and application , t , . . . , iL 

, , ... r r j ■ j « • j * 1 * length elements, storing the variable length array in an 

developers with greater freedom in defining and mampulat- 35 ■ * ' H \ hi 

ing information structures. index-organized table. 

In another approach, the contents of a collection are stored . ^ notner related feature mvolves storiD S> io a aode of the 

in a database column associated with an information object. index-organized table, an identifier of the variable length 

For example, in a method of storage in which each attribute arrav > aD element order value indicating an ordinal position 

of the ADT of an information object is stored in a separate within the variable length array of an element of the variable 

column of a database table, each collection attribute also is 40 length array, and a value of the element, 

stored in a separate column. However, in most database According to another feature, the method also has the 

systems approach this is impractical because the systems steps of establishing the collection storage structure as an 

impose a limit on the size of an element in a column. For index organized table; and storing, in a leaf node of the index 

example, in one known database system each element in a organized table, a value of the collection attribute. Yet 

column must be no larger than 4096 bytes. This is too little 45 moih&t featufe ^des ^ steps of retrieving the 

to accommodate a large nested table or large varying length information object by carrying out the steps of, when the 

arra ^' . information object has at least one collection attribute: 

Thus, there is a need for ways to store information ret rieving the reference to the collection storage structure; 

collections uitegral with information objects. ^ retrieving a vahie of an element of me ejection 

Hiere is also a need for a mechanism that permits infor- 50 atlfibute and de ii V ering the value to an external process only 

mation collections to be stored in association with informa- when the element ^ accessed b the extemal ss 

lion objects as an attribute of the objects. * . , <. ■ , , . „ . . 

rr- . j e r A related feature includes the steps of retrieving the 

lnere is a need for a mechanism providing for storage of . c l- 4 j « 1 c u .* -u * r 

. r A . . » , , . j m . * A • , . information obiect and all values of each attribute thereof 

information objects that have collection attributes in data- u .u • r *• u- * u « *• ** u * 

, A J when the intormation obiect has no collection attribute. 

* j t j t c . r iL In other aspects, the invention encompasses an apparatus. 

Additional objects, advantages and novel features 01 the A r 3 , A , , , . , 

r n , J * r iu • * • *u j ■ *• 1 ■ 1 computer program product, and computer data signal 

invention will be set forth in part in the description which . j. , . b . ' / * 

c „ j - _* n. , , (L r , .„ , . embodied in a carrier wave that are configured to carry out 

follows, and in part will become apparent to those skilled m ^ ^ 0 J 

the art upon examination of the following or may be learned 6 ore S om S s e P s - 

by practice of the invention. The objects and advantages of 60 DESCRIPTION OF THE DRAWINGS 

the invention may be realized and attained by means of the .... 

instrumentalities and combinations particularly pointed out ^ P rcscnt mention is illustrated by way of example, 

in the appended claims. ^ not b ? wa ? of limitation, in the figures of the accom- 
panying drawings in which like reference numerals refer to 

SUMMARY OF THE INVENTION 65 similar elements and in which: 

Jn one aspect, the invention provides a method of storing FIG. 1 is a block diagram of a first mechanism for storing 

an information obiect in a database system, comprising the nested tables. 
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FIG. 2 is a block diagram of a second mechanism for 
storing nested tables. 


FIG. 3 is a flow diagram of a method of storing variable 
length arrays. 5 

FIG. 4 is a flow diagram of a method of retrieving nested 
tables. 

FIG. 5 is a diagram of a computer system with which the 
invention can be implemented. io 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

Mechanisms for storage and use of complex information 15 
objects that include collection attributes, using a database, 
are described. In the following description, for the purposes 
of explanation, numerous specific details are set forth in 
order to provide a thorough understanding of the present 
invention. It will be apparent, however, to one skilled in the 20 
art that the present invention may be practiced without the 
specific details. In other instances, well-known structures 
and devices are shown in block diagram form in order to 
avoid unnecessarily obscuring the present invention. ^ 

INFORMATION OBJECTS THAT CONTAIN 
COLLECTIONS 

Information objects are defined according to abstract data 30 
types (ADTs). In this context, the terms "information object" 
or "data object" refer broadly to elements that can be 
manipulated by a computer program, including objects 
created and used by an application program prepared using 
an object-oriented programming language, and objects ere- 35 
ated by a database server and stored in a database. 

An ADT may have one or more attributes that are data 
collections. Examples of data collections include "varrays" 
and "nested tables". The name varray refers to a data type 40 
that is a variable length array. A varray has ordered elements, 
each accessible using an index value that represents the 
ordinal position of the element. Unlike traditional arrays, a 
varray has no maximum number of elements. In one 
embodiment, an object of type varray is declared having an 45 
initial upper bound. In an alternate embodiment, varray 
objects can be declared with no upper bound. In either 
embodiment, when information is stored in the varray, 
internal system mechanisms allocate elements when they are 
needed, and de-allocate and reclaim space used by elements 50 
when they are not needed. 

A nested table is a database table, maintained by a 
database server, that forms one attribute of an ADT of an 
object. The term "nested" refers to the logical position of the 55 
table within another information structure. A nested table 
attribute has all the attributes of any other table maintained 
by the database server. For example, database server queries 
(such as queries in the Structured Query Language (SQL) 
language) can be applied to a nested table, yielding a view 60 
or a set of records for further manipulation. Nested tables 
store data in rows and columns. The rows in a nested table 
are not inherently ordered. 

As an example, an information object is defined by a 65 
complex abstract data type, "Employee," as shown in Table 
1. 
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TABLE 1 


ADT <EMPLOYEE> 

struct Employee { 

chart 20] Name; 

Date Hired; 

OCtArray "Supervises; 

OCITable *Dept_Name_Tablc; 

int Salary; 

char[ 16] Position; 

int Employ ee_Number 

} 


The ADT of Table 1 describes a hypothetical employee of 
a company and is therefore named Employee. Objects of 
type Employee have a Name attribute that stores the 
employee's name as a string of up to 20 characters. The 
Hired attribute is defined as type Date; the example pre- 
sumes that the programmer has previously defined type Date 
to store calendar dates and that type Date is a character string 
type. The Supervises attribute defines other employees who 
are supervised by this employee. 

The Supervises attribute is an example of what is referred 
to in this context as a varying length array or "varray"; it is 
an array of objects of type Employee that has no upper 
bound or maximum number of elements. The Department 
attribute is nested database table attribute that refers to a 
department name table called Dept__ Names_Table. The 
Salary attribute is an integer that stores the employee's 
annual salary. The Position attribute is a character string that 
stores a description of the employee's job. The Employee_ 
Number attribute is an integer that stores a unique employee 
number for identifying the employee. 

The structure shown in Table 1 is merely an example of 
how an ADT can be declared. In other programming envi- 
ronments and systems, other syntax can be used to accom- 
plish an equivalent result. Such other mechanisms for 
declaring ADTs are fully within the scope of the invention. 

In an embodiment, a database system stores information 
objects that are declared according to ADTs. The database 
system also stores metadata that describes the ADT of each 
information object. For example, the database system stores 
Type Descriptor Segments, Type Descriptor Objects, Format 
Descriptor Objects, and Location Descriptor Objects that 
define characteristics of information objects managed by the 
system. The metadata are stored in database tables so that 
they are rapidly accessible by the database system. The 
structure and use of such metadata are fully described in 
co-pending U.S. patent application Ser. No. 08/961,795, 
entitled "Apparatus and Method for Pickling Data," attorney 
docket number 3018-092 (OID 1997-10-01), which is 
hereby incorporated by reference as if fully set forth herein. 

STORAGE MECHANISMS FOR NESTED 
TABLES 

FIG. 1 is a diagram of how a nested table attribute of an 
Employee object can be represented in computer memory. In 
this embodiment, objects are created and managed by a 
database server application program. One suitable database 
server is the Oracle8 database server commercially available 
from Oracle Corporation, Redwood Shores, Calif. Database 
servers have the integral capability to create and manipulate 
tables of information in memory. 

In FIG. 1 a nested table storage mechanism comprises a 
base table 10, a storage table 20, and a dictionary table 30. 
The base table 10 has rows 14a, 146, 144c, 14d and columns 


55 


60 
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12a, 12b, 12c, and 12a*. Table 10 is shown in FIG. 1 having 
four rows and four columns by way of example only; each 
of the tables described in this document can have any desired 
number of rows and columns. The lines that connect rows 
14c and 14a*, and columns 12c and 12d, indicate that any 
number of rows or columns may be used in the base table 10. 

In the preferred embodiment, each row 14a-14d of base 
table 10 stores one information object, and each column 
12a- Hd stores one attribute of the ADT for an information 
object that is stored in a particular row. Thus, for example, 
when an object of type Employee is stored in one row 14a 
of the table 10, data for the first attribute (Name) is stored 
in column 12a of row 14a, data for the second attribute 
(Hired date) is stored in column 126 of row 14a, and data for 
other attributes is stored in successive columns. The data- 
base server creates and maintains a separate base table 10 for 
each ADT that is defined in the system. In this way, each 
object that is active in the database system maps to a row of 
the base table 10 for a particular type, and each attribute of 
the type maps to a column of that table. In one alternate 
embodiment, each column stores an image produced by 
applying data of an attribute to a pickier process. 

An attribute of an object can be a nested table, that is, an 
attribute of an object can be defined as a table that is nested 
within the object. In such a case, table 10 is called a base 
table, and it is related through one column 12d to a storage 
table 20. Column 12d stores nested table references 16a, 
166, 16c. The storage table 20 has unordered rows 36a, 366, 
36c, 36c/, 36e, 36/. Groups of the rows 36a-36/ correspond 
to a nested table reference 16a, 166, 16c in column 12d. The 
storage table has an identifier column 22, and data columns 
24, 26 (and others if needed) that store data. However, the 
value of each nested table reference 16a-16c maps uniquely 
to one group of rows in the storage table 20. Thus, the 
storage table 20 can be regarded as a group of nested tables 
all having the same type. For example, rows 36a and 36c 
each have the same setid value, and therefore belong to a 
first nested table. Rows 366, 36a* belong to a second nested 
table. Accordingly, even though the rows in the storage table 
20 are unordered, using the value in the identifier column 22, 
the system can retrieve and assemble nested tables. 

For example, as shown in FIG. 1, when an Employee 
object is stored in base table 10, the Department attribute is 
represented by column 12d. Column 12d stores an identifier 
16a that refers to a portion 28a of the storage table 20 that 
stores Department information for the object of row 14a. 
Each row 36a-36/of the storage table 20 stores one object 
of the base type of the storage table 20. Each column 24, 26 
stores data for one attribute of objects of the base type of the 
storage table 20. Thus, when a base table 10 has multiple 
unique nested table identifiers 16a, 164c, each such identi- 
fier maps to a different portion 28a, 286 of the storage table 
20. In this way, a single storage table 20 stores more than one 
logical nested table that is referenced in the base table 10. In 
one embodiment, identifiers 16a, 166, 16c are called "set 
identifiers" or "setid"s. 

In the preferred embodiment, the column \2d is a hidden 
column having the name NESTED_TABLE_ID. 

The storage table 20 and the base table 10 are interrelated 
using entries in a dictionary table 30. The dictionary table is 
a database table managed internally by the database server. 
Each row of the database table stores an identifier of a table 
that is active in the database system. Each column stores 
identifiers of related tables, characteristics, and other meta- 
data relating to the active tables. Thus, for a given table that 
is active in the database system, there may be many rows in 
the dictionary table referring to that table. 
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In the example of FIG. 1, the dictionary table 30 has rows 
31a, 316 and columns 32, 34. Column 32 stores base table 
identifiers. Column 34 stores nested table identifiers. If a 
particular base table has references to multiple nested tables, 
5 then in the dictionary table 30 there would be a row for each 
reference, and the nested table identifier column 34 would 
identify each nested table that is referred to in an object of 
the base table. Using a dictionary table structured in this 
way, a database server can locate a nested table based on a 
base table identifier. 

FIG, 2 shows an alternate embodiment of the mechanism 
of FIG. 1. In this embodiment, the storage table 20 is stored 
in the form of an index-organized table ("IOT 5 ) 40. An 
index-organized table is an ordered database table that has 
15 the conceptual structure of a binary tree. Generally, binary 
trees are well known in the art; they are described, for 
example, in the Knuth reference cited above, at section 2.3. 
Index -organized tables are described in detail in co-pending 
U.S. patent application Ser. No. 08/764,112, now U.S. Pat. 
20 No. 5,852,822 "Index-Only Tables With Nested Group 
Keys", which is incorporated by reference as if fully set 
forth herein. 

In the IOT 40, each leaf node stores a row of the nested 
table. In one embodiment, the leaf nodes are data structures 

25 that are initialized and allocated having the same structure as 
the ADT of the base type of the nested table. For example, 
when the IOT 40 represents the Department_Name_Table 
attribute of the Employee object ADT of Table 1, each leaf 
node is a data structure of type Department, because that is 

30 the base type of the nested table attribute. Branch nodes of 
the IOT 40 store a key value comprising a concatenated 
primary key and index value. The primary key of the IOT is 
specified by the user when the IOT is declared. The index 
value indicates the table membership of multiple rows that 

35 have the same primary key value in the IOT. 

For example, as shown in FIG. 2, the primary key is the 
social security number of the employee represented by the 
Employee object of Table 1, and the branch nodes of the IOT 
40 store a concatenated key value 42 comprising a setid 22 

40 and the social security number or index value 44. For clarity, 
column 26 of the IOT 40 is shown as storing the surname of 
the employee. If multiple rows of the IOT have the same 
social security number value, the setid is used to indicate 
that the rows belong to different nested tables that are 

45 identified by the setid. In this way, multiple nested tables 
each having multiple rows are ordered within the IOT 40. 

Rows of a particular table are located by walking the tree 
and examining the setid at each leaf node. 
When a varray is stored in an IOT, the varray index value 

50 is used to order the rows of the IOT, rather than the primary 
key. This technique is used in order to preserve the ordering 
of the varray elements, i.e., to ensure that element 4 of a 
particular varray object is ordered in the IOT before element 
5. 

55 In one embodiment, a nested table can be declared with- 
out an underlying object type. 

When a nested table is declared and its elements are not 
declared to have an object type, the database server creates 
the table with a single unnamed column. The internal 

60 database server keyword COLUMN_VALUE represents 
the name of the column, and can be used to access elements 
in the nested table. 

STORAGE MECHANISMS AND METHODS 
65 FOR VARRAYS 

In one embodiment, ADT attributes of information 
objects are declared to be of type varray, and the attributes 
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are stored in a database system. Several different storage attribute are always stored in an IOT. As shown in block 318, 

mechanisms are used according to the potential storage each leaf node of avarraylOT stores a data triple comprising 

space needed for the varray and the size of its elements. a varray identifier, a non-unique element order number, and 

FIG. 3 is a flow diagram of a method of selecting a storage a dala value for that element. In one embodiment, the unique 

mechanism for varray attributes. In step 302, a varray 3 varray identifier is a set identifier called a send. Thus, each 

attribute of an ADT is identified. For example, a varray leaf node contains information identifying which varray is 

attribute is recognized by a database server in the compila- represented in the leaf node, which element of that varray is 

tion phase of processing an application program, when an represented in the leaf node, and the value of the element, 

object is declared based on an ADT that has a varray When the varray attribute has been fully evaluated and 

attribute. 10 one of the three storage mechanisms (database column, 

Varrays may be declared with base elements that have a L0B > or I0 T) nas been selected, the method is complete as 

fixed length or a varying length. For example, an ADT shown by block 314. 

attribute is declared to be a "varray [150] of integer/ 5 Such RETRIEVING COLLECTIONS 
a varray has up to 150 elements, each of which is an integer. 

The "integer" designation indicates that the varray has fixed 15 FIG. 4 is a flow diagram of a method of retrieving an 

length elements, because integers are always stored in a object that contains a collection attribute from a storage 

fixed amount of storage space, e.g., four bytes. In contrast, location. In an embodiment, FIG. 4 represents processing 

an ADT attribute also can be declared to be a "varray [150] steps carried out when an object having a collection attribute 

of CharString" in which the type "CharString" is a varying is retrieved from non-volatile storage, such as disk, to 

length character string. In that case, the base type of the 20 volatile storage, such as an object cache of a database server 

varray does not have a fixed length. that needs the object, or local memory of a machine or 

If the varray attribute is declared with base elements that process that needs the object, 
have fixed length, as indicated in block 304 of FIG. 3, then In block 402, an application program requests an infor- 
the attribute is either stored in a database column or a large mation object. Block 402 is intended to broadly reflect any 
object ('"LOB"), depending on the maximum storage space process of requesting an information object that is under 
required for an instance of the attribute. The maximum management by a database server or other process or pro- 
storage space required for an attribute is calculated by gram that implements the invention. For example, block 402 
multiplying the maximum number of elements declared in represents a request by a database server to obtain an 
the varray declaration and the size of each element, as shown 3Q information object that is needed to carry out an application 
in block 306. For example, when an attribute is declared as program running under control of the server, 
"varray [150] of integer," and integers are stored in four In block 404, the object's ADT is examined to determine 
bytes, the maximum storage space required is 600 bytes per whether the object has a collection attribute. In an 
instance of that attribute. embodiment, this step is carried out by retrieving metadata 

As shown in block 308, if the maximum size of an 35 that describes the type of the object from a table of the 

instance of a varray is less than the maximum size of a database system. For example, each information object 

database column, then in block 312 values of the varray includes a type identifier that is stored in association with 

attribute are stored in a column of the base table 10 just like data values and methods of the object. Using the type 

any other attribute. In the preferred embodiment, the maxi- identifier, the database system looks up metadata about that 

mum size of a value of a database column is 4096 bytes. ^ type of object in an object type table. The database system 

Therefore, in the preferred embodiment, when a varray retrieves a type descriptor object corresponding to the 

declaration indicates that the maximum size of an instance object's type from that table, and interprets the information 

of the varray attribute is 4096 bytes or less, then values of in the type descriptor object. The type descriptor object has 

the varray attribute are stored in a database column. fields that indicate the data type of each attribute of an 

If the storage space needed for an instance of a varray 45 ob i ect - Collections including nested tables and varrays are 

attribute is potentially larger than 4096 bytes, then as shown indicated by unique codes in the attribute fields of the type 

in block 310 the varray is stored in a database object of type descriptor object. 

Large Object ("LOB"). LOB is the name used for a data type If the metadata indicates that the object does not have any 

that represents very large data objects. LOBs may be much collection attributes, then as shown in block 406, the entire 

larger than traditional data types. For example, a single LOB 50 object is retrieved from its location in non-volatile storage 

may include four gigabytes of data. LOBs are managed and a nd copied into volatile storage, such as the object cache. At 

supported by existing mechanisms in a database server. For this point, the object is ready for further use by an applica- 

exarople, LOBs are managed by the Oracle8 database server. tion program, and the method is considered complete, as 

The use, management, and operation of LOBs are described shown in block 408. 

in more detail in "Oracle8 Server On-Line Generic Docu- 55 If the object contains a collection attribute, it is desirable 

mentation CD-ROM" available from Oracle Corporation, not to retrieve the values or other contents of the collection 

Redwood Shores, Calif, (part number A55 125-01), and two attribute until they are actually needed by the database 

co-pending U.S. Patent Applications, each of which is server or a related application program. Collection 

hereby incorporated by reference as if fully set forth herein: attributes, such as nested tables, may be quite large. 

U.S. patent application Ser. No. 08/962,487, now allowed 60 Accordingly, if the entire collection attribute is always 

"LOB Locator," Attorney Docket Number 3018-097 (OID- retrieved when an object is requested, it is possible that the 

1997-10-06), and U.S. patent application Ser. No. 08/962, available volatile storage space associated with the request- 

132, now allowed "LOB Indexing," Attorney Docket Num- ing program or process will be insufficient. The address 

ber 3018-107 (OID- 1997-10-14). space may overflow. 

If a varray attribute is declared to have varying length 65 Therefore, as shown in block 410, when a requested 

elements, then the test of block 304 will be negative. In that object has a collection attribute, only an identifier of the 

case, as shown in block 316, instances of that varray collection attribute is retrieved and returned to the request- 
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ing program or process. The identifier is a handle or refer- functions that operate specifically on nested tables are 

ence to the values of the collection. For example, in an identified by the prefix OCITable. The nested table functions 

embodiment, the identifier is a value comprising a base table are described in the section below entitled "Nested Table 

identifier concatenated with a "setid", and when the Manipulation Functions." 

requested object is delivered to the calling program, the 5 An application program can allocate an instance of a 

object contains the identifier in the position of the collection varray or nested table using the function OCIObjectNew( ) 

attribute. an d free an instance using OCIObjectFree. The generic 

Block 412 represents processing steps in which the con- collection functions carry out two other main types of 

tents of the collection attribute remain untouched until they processes: manipulating varray or nested table data, and 

are needed by a calling program or process. Thus, the 10 scanning through a collection with a collection iterator, 

collection attribute remains in non-volatile storage until an When an index variable or value is passed to a collection 

element of the collection is actually requested or needed by function, the minimum value of the index variable is pref- 

the database server or a related program. In that event, as erably zero. 

shown in block 414, in one embodiment, a partition of the r „ rtmTrtfcT _ ArT , A A kT ™, T ™ rtfcT 

Qon-vola«ile storage device that contains the needed element 15 COLLECTION ^MANIPULATION 

value is retrieved into local volatile storage, or into the 

object cache. Preferably, the partition is pinned or locked so The preferred embodiment has functions that manipulate 

that other programs or processes cannot modify the partition collection data. The names and functions of the generic 

while the collection element value is in use. In block 416, the functions are summarized in Table 2 below, 

value of the element is delivered to the database server or the 20 

calling program. TABLE 2 

IMPLEMENTATION OF MECHANISMS AND COLLECTION DATA MANIPULATION FUNCTIONS 

METHODS 

Function Purpose 
25 1 


Jn «hr. pryfrrrrH rmbnrlimr i nt J t in i n - ' hnni i mi nnrl mrth 

, r . A . . . . . . , . , , r c OCICollAppcndO append an element 

odsof the invention are implemented in the form of one or oaCollAsSgnElemO assign element at given index 

more computer program functions, procedures, process es, oaCoilAssignO assign one collection to another 

objects, or meth ods that can be incorporated into an appli- OClCollGctElemO get pointer to an element given its index 

Nation program that need s to manipulate nested tables.J n oacollMaxp get upper bound of collection 

^ £— -S ; n — p — TT~- i TT^ r 30 OCICollSizeO get current size of collection 

One embodiment, collections are supported in a plurality of oaCo i 1Trini ^ ^ n c]emcnts &am ^ end of thc 
database server functions. Farjh nf «hr, functions has a name 


'and receives a set or jj^Tameters . T he set of all functio n 

naffleS and their parameters de fines an Application Prog ram- Each of the functions named in Table 2 is called by 

ming Interlace (Ap\) toThe functions. An example o f this including an appropriate function call statement in an appli- 

embodiment is the API called the Oracle Call Inter face 35 cation program that is linked to the function, a library of the 

fnn] _j .rr";jfc f| in th <* fwi « g rintnhnr^ ronrpr, mmmpr. functions, or to the database server. Each function call 

ciah yavailable from Oracle Corporation. passes, as a parameter to the function call, a handle or 

""Preferably, the functions are classified as nested table P ointer t0 a collection that is to be manipulated. Additional 

functions, variable length array (varray) functions, generic ^ Parameters are passed to the functions depending on the 

collection functions that work with either nested tables or Dature of the work carned out b V me faction, 

varrays, and iteration functions that are used to work with Th e function OCICollAppend( ) is called with an element 

individual elements of a collection. In one embodiment, the value, or a handle or pointer to an element value, as a 

functions in these four groups have names beginning with parameter. The function allocates storage space for an addi- 

the labels OCITable, OCIArray, OCIColl, and OCIIter, 45 tional element, and stores the element value in the newly 

respectively. In this embodiment, an application program allocated space. 

written in the C language declares an object of type varray The function OCICoUAssignElem( ) is called with an 

using the syntax OCIArray *, and nested table objects are element value, and an index value. The index value indicates 

represented as OCITable *. All the function names and an ordinal position within the collection. The function 

object names presented in this document are provided 5Q locates the requested position and assigns the element value 

merely as examples; any other names may be used within the to the element at that position. 

spirit and scope of the invention. The function OCICollAssign( ) is called with a source 

„ „ collection identifier and a destination collection identifier. 

GENERIC COLLECTION FUNCTIONS ^ function locates a col , ecti(m by ^ gaam 

In an embodiment, generic collection functions are pro- 55 collection identifier, and copies the information in that 

vided that enable an application program to manipulate collection into the collection that is identified by the desti- 

collection data. These functions are called "generic" because nation collection identifier. 

an application program can apply the functions to any The function OCICollGetElem( ) is called with a collec- 

collection type including varrays and nested tables. Other tion index value as a parameter. The collection index value 

functions, discussed below, are specific to nested tables. 50 represents the ordinal position of an element of the collec- 

Thus, varrays and nested tables can be viewed as sub -types tion. The function locates the element that is indicated by the 

of a generic collection type. collection index value, and returns a pointer to that element. 

In one embodiment, in application programs written in the The function OCICollMax( ) is called with no parameters 

C language, a generic collection is represented as OCIColl other than a collection identifier. The function returns an 

*. In the preferred embodiment, the generic collection 65 integer value representing the number of items or upper 

functions operate on generic collection objects (such as bound of the collection. For example, when a varray object 

OCIColl *) as well as varrays and nested tables. Additional is declared as "varray [150] of char," the function would 
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return the value "150" regardless of whether 150 values are 
actually stored in the object. 

The function OCICollSize( ) also is called with no param- 
eters other than a collection identifier. The function returns 
an integer representing the number of values in the 
collection, that is, the current size of collection. For 
example, when a varray object is declared as "varray [150] 
of integer," and 16 values have been stored in the object, this 
function would return the value 16 for that object. 

The function OCICollTrim( ) is called with an integer 
value as a parameter. The value represents a number of 
elements to be removed or "trimmed" from the end of a 
collection object. The function returns a Boolean value 
indicating whether the trim operation was successful. 

COLLECTION SCANNING FUNCTIONS 

The preferred embodiment also has generic functions that 
enable an application program to scan collections using a 
collection iterator. The collection iterator is a value declared 
of type OCIIter. The collection scanning functions are 
summarized in Table 3 below. 


TABLE 3 


Function 


COLLECTION SCANNING FUNCTIONS 


Purpose 


OCUterCreateQ create an iterator for scanning collection 

OCUterDeleteO delete iterator 

OCIIteiGetCurrentO get pointer to current element pointed by iterator 

OCIIterlnitQ initialize iterator to scan the given collection 

OCIIterNextO get pointer to next element 

OCIIter PrevQ get pointer to previous element 


The functioD OCUterCreate( ) is called to create an 
iterator object for a specified collection. It returns a handle 
to the iterator object that it creates. The iterator is initialized 
to point to the beginning of the collection. 

The function OCIIterDelete( ) is called using a handle or 40 
pointer to an iterator as a parameter. The function deletes the 
iterator that is identified by the parameter. 

The function OCIIterGetCurrent( ) is called using an 
iterator and a collection as parameters. The function locates 
the element at the position indicated by the iterator, and 45 
generates a pointer to that element. The function returns the 
element pointer to the calling program. 

The function OCIIterInit( ) is called using an iterator and 
a collection as parameters. The function initializes the 
iterator to point to the beginning of the collection. The 50 
iterator can then be used in subsequent function calls. 

The function OCIIterNext( ) is called using an iterator as 
a parameter. The function locates an element at the next 
position greater than the iterator, and returns a pointer to that 
element. It also increments the iterator. If there is no next 
element, the function returns an error code or raises an 
exception. The OCIIterPrev( ) operates similarly to the 
function OCHterNext( ), but the function OCIIterPrev( ) 
returns a pointer to the previous element in relation to the 60 
iterator that is passed as a parameter. 

Collection iterators and the above-defined functions can 
be used to scan through a varray and perform numerous 
useful functions. An example of such an operation, in which 
collection iterators are used to generate a printout of the 65 
contents of a collection object, is provided in the code 
segment provided in Table 4 below. 


55 


14 


TABLE 4 


10 


15 


20 


CODE EXAMPLE: SCANNING A VARRAY 

OCIEnv 

•envhp; 

OCIError 

•errhp; 

text 

*text_ptr; 

sword 

status; 

OCIArray 

•clients; 

OCIString 

*client_elem; 

OCHter 

•iterator; 

boolean 

eoc; 

dvoid 

•elem; 

Oaind 

"elemind; 

/* Assume envhp, errhp have been initialized */ 

/* Assume clients points to a varray V 


/* Print the elements of clients */ 
/* To do this, create an iterator to scan the varray */ 
status - OCIIterCrcate(envhp, errhp, clients, & iterator); 
/* Get the first element of the clients varray */ 
printfC'Clients* list:\n"); 

status = OCIIterNext(envhp, errhp, iterator, &eLem, 

(dvoid * *) &elemind, &eoc) 
while (!eoc && (status == OCL_SUCCESS)) 
{ 

clicnt_elem » •(OCIString* *) elem; 
/* client_elem points to the string 7 


25 


the element pointer type returned by OCIIterNextO via 'elem* is 
the same as that of OCICotlGetElemO- Refer to OCICollGetElemO 
for details. */ 

client_elem points to an OCIString descriptor, so to print it out, 
get a pointer to where the text begins 


30 text_ptr - OCIStringPtr(envhp, client_elem); 


r 


text_ptr now points to the text part of the client OCIString, 
which is a NULL- terminated string 


* ocr__succEss) 


printf(" %s\n", text_ptr); 

status " OCIIterNext(envhp, errhp, iterator, &elem; 
(dvoid ")&elemind, &eoc); 

} 

if (status ! 
{ 

/* handle error*/ 
} 

/* destroy the iterator */ 
status o OCIIterDelete(envhp 1 errhp, ^iterator); 


NESTED TABLE MANIPULATION FUNCTIONS 

As noted above, the generic collection functions may be 
used to map to and manipulate nested tables. In addition, the 
preferred embodiment has functions for manipulating nested 
tables. These nested table manipulation functions are sum- 
marized in Table 5 below. 

TABLES 

NESTED TABLE MANIPULATION FUNCTIONS 
Function Purpose 


OClTabLeDeleteO delete an element at a given index 

OCITableExistsO test whether an element exists at a given index 

OCITableFirstO return index for first existing element of table 

OClTableLastO return index for last existing element of table 

OCITableNextO return index for next existing clement of table 

OCTTablePrevQ return index for previous existing element of table 

OCfTableSizeQ return table size, not including deleted elements 


The function OClTableDelete( ) is called to delete ele- 
ments from a nested table. An index value is passed to the 
function as a parameter, and the function deletes the ele- 
ments at that index location. For example, a table is created 
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with 10 elements, and OCITableDelete( ) is used to delete As a second example, assume that an application program 

elements at index 0 through 4 and 9. Then, the first existing declares a class of objects called type line_item list t. A 

element is element 5, and the last existing element is element data unit of that type is a nested table, each row of which 

8. contains a line _jtem_t object. The nested table of line items 

The function OCITableExists( ) is called with a collection 5 represents a purchase order. A nested table of line items is 

handle and an index value as parameters. The function tests Detter choice to represent the line item list of a purchase 

whether an element exists in the collection at the index that ordcr ^an a varray of line_item_t objects would be, for the 

is passed as a parameter. It returns a Boolean value that is following reasons. First, querying the contents of line items 

TRUE when the element exists in the collection. k likely to be a requirement for most applications that use 

Hie function OCITableFirst( ) is called using a handle or 10 P urcbasc orders Varrays can be directly queried by the 

pointer to a table as a parameter. Hie function locates the database but ^hqueries are not efficient. When a 

indicated table, identifies the first existing element in the varra y 15 slor * d m . a LOB or databasc table ™ lumn ' * 15 

table, and returns an integer value representing the ordinal stored 35 a P ickled J° c ^ out t a ^ the databa f 

value or index for the first existing element of the table. server ^ us ? accessor functions to locate elements of the 

™ r „„™ , , . , . , , „, ,. ,15 varray within the image. In contrast, when a varray is stored 

The functions OCTTahleI . astf \ QqTnh 1p, N nrt ( ), an d k m WT as describcd herei it ^ DOt storcd in icMcd 

OCITablePrev( ^ receive the same Parameter and carry out ; form ^ can be ried 

steps similar to the function u^i laoieFi rsu ), but re turn „ , . , . . , 

i ndex values for th « l«t ™Tt .-H pr. vin.. Jl^nt. in the . Second > °° ^ fata may be a requirement 

' table respectively in some applications. Nested tables allow this, but it is not 

. — - ' . — rt " TrT1 , , . 20 possible with varrays. Third, the order of line items is 

The function OCITableS^eQ receives a handle or pointer usua]1 ^ tant; ^ the tim item num5er can be ^ 

to a table as a parameter. The tunction returns an integer tQ ^ an order when nec ^ there k no 

value th* represent .ne sae in elemems, 01 the table. In ^ bound Qn ^ number of ^ items on a 

computing the size value, the function ignores deleted purchase order 

elements. 9« 


NESTED TABLE ELEMENT ORDERING 


HARDWARE ENVIRONMENT 


When a nested table is fetched into the object cache, its F f lG ' a bloc * diagram that illustrates a computer 

, , , * i j ■ system 600 upon which an embodiment of the invention 

elements are given a temporary or transient ordering, num- L • , . j ^ . * ■ i j l 

• j r> , , < i ci , -it*™ mav De implemented. Computer system 600 includes a bus 

bered from zero to the number of elements, minus 1. For 30 £tv f r ■ *■ L ■ r • ^ 

i 4 Li %u An i * ,j . . . r 602 or other communication mechanism for communicating 

example, a table with 40 elements would be numbered from . c , ^ M . , . iL , + M c 

n . ^ a a i information, and a processor 604 coupled with bus 602 for 

0 to 39. An application program can use these position . . ' 5 ^ . \ ^ - 1 j 

j* i * r * if j * *u i c i * /c processing information. Computer system 600 also includes 
ordinals to fetch and assign the values of elements (for r & , * J , 

? . , v . a mam memory 606, such as a random access memory 

example, fetch to element l, or assign to element j, where 1 /ri A _ _v t . J , . . , . i , . . 

j ■ . 4 . j* i r lL * t_V\ « (RAM) or other dynamic storage device, coupled to bus 602 

and j are valid position ordinals for the given table). ^ \ ' ' j . . .5 

J r 6 7 for storing information and instructions to be executed by 

When the table is copied back to the database, its transient proce ssor 604. Main memory 606 also may be used for 
ordering is lost. Delete operations may be performed against storing temporary variables or other intermediate informa- 
elements of the table. Delete operations create transient don during execution of instructions to be executed by 
"holes"; that is, they do not change the position ordinals of proC e SS or 604. Computer system 600 further includes a read 
the remaining table elements. only memory (ROM) 608 or other static storage device 

APPLICATIONS OF VARRAYS AND NESTED t0 buS 602 ^^f^^^^^> 

TABLES S P rocessor 604. A storage device 610, such as a 

magnetic disk or optical disk, is provided and coupled to bus 

Varrays and nested tables are best suited to different 45 602 for storing information and instructions, 
applications. For example, an application program needs to Computer system 600 may be coupled via bus 602 to a 
manage a list of telephone numbers. The list of phone d isplay 612. such as a cathode ray tube (CRT), fo r displayin g 
numbers can be stored in either a varray or a nested table. i nformation to a computer user. An input device 614, includ- 
Suppose the list represents contact phone numbers for a ing alphanumeric ancPdlker keys, is coupled to bus 602 for 

single customer in a product ordering application. A varray 50 communicating information and command selections to 
is a better choice than a nested table for several reasons. processor 604. Another type of user input device is cursor 

First, the order of the numbers might be important. control 616, such as a mouse, a trackball, or cursor direction 
Varrays are ordered. Nested tables are unordered. Second, keys for communicating direction information and com- 
the number of phone numbers for a specific customer is mand selections to processor 604 and for controlling cursor 

small. To use a varray, the application program must specify 55 movement on display 612. This input device typically has 
a maximum number of elements (ten, in this case) in two degrees of freedom in two axes, a first axis (e.g., x) and 
advance. They use storage more efficiently than nested a second axis (e.g., y), that allows the device to specify 
tables, which have no special size limitations. Also, there is positions in a plane. 

no reason to query the phone number list, so the table format The invention is related to the use of computer system 600 

offers no benefit. 60 f or storing and using pickled images of information objects 
In general, if ordering and bounds are not important in database tables, storing object collections, and storing and 
design considerations, then the following rule can be used to using null objects. According to one embodiment of the 
decide whether to use a varray or a nested table in a invention, such object storage and use is provided by com- 
particular application: If the application program needs to puter system 600 in response to processor 604 executing one 

query the information collection, a nested table should be 65 or more sequences of one or more instructions contained in 
used. If the application program needs to retrieve the col- main memory 606. Such instructions may be read into main 
lection as a whole, a varray is preferable. memory 606 from another computer-readable medium, such 
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as storage device 610. Execution of the sequences of instruc- 
tions contained in main memory 606 causes processor 604 
to perform the process steps described herein. One or more 
processors in a multi-processing arrangement may also be 
employed to execute the sequences of instructions contained 
in main memory 606. In alternative embodiments, hardwired 
circuitry may be used in place of or in combination with 
software instructions to implement the invention. Thus, 
embodiments of the invention are not limited to any specific 
combination of hardware circuitry and software. 

The term "computer-readable medium" as used herein 
refers to any medium that participates in providing instruc- 
tions to processor 604 for execution. Such a medium may 
take many forms, including but not limited to, non-volatile 
media, volatile media, and transmission media. Non-volatile 
media includes, for example, optical or magnetic disks, such 
as storage device 610. Volatile media includes dynamic 
memory, such as main memory 606. Transmission media 
includes coaxial cables, copper wire and fiber optics, includ- 
ing the wires that comprise bus 602. Transmission media can 
also take the form of acoustic or light waves, such as those 
generated during radio wave and infrared data communica- 
tions. 

Common forms of computer-readable media include, for 
example, a floppy disk, a flexible disk, hard disk, magnetic 
tape, or any other magnetic medium, a CD-ROM, any other 
optical medium, punch cards, paper tape, any other physical 
medium with patterns of holes, a RAM, a PROM, and 
EPROM, a FLASH-EPROM, any other memory chip or 
cartridge, a carrier wave as described hereinafter, or any 
other medium from which a computer can read. 

Various forms of computer readable media may be 
involved in carrying one or more of one or more instructions 
to processor 604 for execution. For example, the sequence 
instructions may initially be carried on a magnetic disk of a 
remote computer. The remote computer can load the instruc- 
tions into its dynamic memory and send the instructions over 
a telephone line using a modem. A modem local to compute r 

system 600 can receive the data'on the telephone line and ^ ^^gs are, accordingly, to be regarded in an illus- 
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equipment operated by an Internet Service Provider (ISP) 
626. ISP 626 in turn provides data communication services 
through the world wide packet data communication network 
now commonly referred to as the "Internet" 628. Local 
network 622 and Internet 628 both use electrical, electro- 
magnetic or optical signals that carry digital data streams. 
The signals through the various networks and the signals on 
network link 620 and through communication interface 618, 
which carry the digital data to and from computer system 
600, are exemplary forms of carrier waves transporting the 
information. 

Computer system 600 can send messages and receive 
data, including program code, through the network(s), net- 
work link 620 and communication interface 618. In the 
Internet example, a server 630 might transmit a requested 
code for an application program through Internet 628, ISP 
626, local network 622 and communication interface 618, In 
accordance with the invention, one such downloaded appli- 
cation provides for storing and using pickled images of 
information objects in database tables, storing object 
collections, and storing and using null objects, as described 
herein. 

The received code may be executed by processor 604 as 
it is received, and/or stored in storage device 610, or other 
non-volatile storage for later execution. In this manner, 
computer system 600 may obtain application code in the 
form of a carrier wave. 

EXTENSIONS AND APPLICATIONS 

The methods and mechanisms described herein provide 
efficient ways to accomplish data storage in a database 
system. For example, objects stored in the form of images in 
a database table can serve as a backing store for objects in 
memory, replacing storage of graphs in memory, or caches. 

In the foregoing specification, the invention has been 
described with reference to specific embodiments thereof. It 
will, however, be evident that various modifications and 
changes may be made thereto without departing from the 
broader spirit and scope of the invention. The specification 


signal. An jnfrared detector coupled to bus 602 can re ceive 
the da ta carr ied lnlhe infrared signal and~place the dat a on 
bus 602. Bus 602 ca rries the data to main mem or y 606, from 
which processorT04 retrieves and executes tHeinstructions. 
The instructions received by main memory 606 may option- 
ally be stored on storage device 610 either before or after 
execution by processor 604. 

Computer system 600 also includes a communication 
interface 618 coupled to bus 602. Communication interface 
618 provides a two-way data communication coupling to a 
network link 620 that is connected to a local network 622. 
For example, communication interface 618 may be an 
integrated services digital network (ISDN) card or a modem 
to provide a data communication connection to a corre- 
sponding type of telephone line. As another example, com- 
munication interface 618 may be a local area network 
(LAN) card to provide a data communication connection to 
a compatible LAN. Wireless links may also be implemented. 
In any such implementation, communication interface 618 
sends and receives electrical, electromagnetic or optical 
signals that carry digital data streams representing various 
types of information. 

Network link 620 typically provides data communication 
through one or more networks to other data devices. For 
example, network link 620 may provide a connection 
through local network 622 to a host computer 624 or to data 
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What is claimed is: 

1. Amethod of storing an information object in a database 
system, comprising the steps of: 

establishing an information object class that has a collec- 
tion attribute; 

creating said information object as an instance of said 

information object class; 
establishing in said database system a collection storage 

structure for said collection attribute; 
storing attribute information about said information 

object in a first table; 
storing values of said collection attribute in said collection 

storage structure; and 
wherein said attribute information that is stored in said 

first table includes a reference that indicates where said 

values of said collection attribute for said information 

object are stored in said collection storage structure. 

2. The method recited in claim 1, further comprising the 
steps of: 

establishing a second table in said database system; 
storing a first identifier that identifies said first table and 

a second identifier that identifies said collection storage 

structure; and 

storing within said second table a record that associates 
said first identifier with said second identifier. 
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3. The method of claim 2, wherein said information object 
class has another collection attribute, and wherein the 
method further comprises the step of 

storing within said second table a second record, 
wherein said second record associates said first identifier 
with a third identifier that identifies another collection 
storage structure, wherein said other collection storage 
structure is used to store values that belong to said other 
collection attribute. 

4. The method recited in claim 1, further comprising the 
steps of: 

establishing said collection storage structure in the form 
of a storage table in said database system; 

establishing in said storage table, at least one nested table 
portion comprising rows of values of said collection 
attribute associated with said reference; and 

storing a copy of said reference in a column of said 
storage table. 

5. The method recited in claim 1, wherein said step of 
establishing an information object class that has a collection 
attribute comprises the step of establishing a variable length 
array as said collection attribute of said information object 
class. 

6. The method recited in claim 5, further comprising the 
steps of: 

when said variable length array is defined having fixed- 
length elements: 

computing a maximum size value representing an 
amount of storage space required for an instance of 
said variable length array; and 

storing said variable length array in a database column 
when said maximum size value is equal to or less 
than a pre-defined maximum database column size 
value. 

7. The method recited in claim 6, further comprising the 
step of storing said variable length array in a large object 
structure when said maximum size value is greater than said 
maximum database column size value. 

8. The method recited in claim 5, further comprising the 
step of: 

when said variable length array is defined having 
variable-length elements, storing said variable length 
array in an index-organized table. 

9. The method recited in claim 8, further comprising the 
step of storing, in a node of said index-organized table, an 
identifier of said variable length array, an element order 
value indicating an ordinal position within said variable 
length array of an element of said variable length array, and 
a value of said element, 

10. The method recited in claim 1, further comprising the 
steps of: 

establishing said collection storage structure as an index 

organized table; and 
storing, in a leaf node of said index organized table, a 

value of said collection attribute. 
U. The method recited in claim 1, further comprising the 
steps of: 

retrieving said information object by carrying out the 
steps of: 

when said information object has at least one collection 
attribute: 

retrieving said reference to said collection storage 

structure; and 
retrieving a value of an element of said collection 

attribute and delivering said value to an external 
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process only when said element is accessed by 
said external process. 

12. The method recited in claim 11, further comprising the 
steps of: 

5 retrieving said information object and all values of each 
attribute thereof when said information object has no 
collection attribute. 

13. A computer apparatus for storing an information 
object in a table of a database system, said computer 

10 apparatus comprising: 
a processor; and 

a memory coupled to said processor; the memory having 
stored therein a database system; and 
15 sequences of instructions which, when executed by said 
processor, cause said processor to store said informa- 
tion object in said database system by causing the 
processor to perform the steps of: 

establishing an information object class that has a collec- 
2Q tion attribute; 

creating said information object as an instance of said 
information object class; 

establishing in said database system a collection storage 
structure for said collection attribute; 
25 storing attribute information about said information 
object in a first table; 

storing values of said collection attribute in said collection 
storage structure; and 
3Q wherein said attribute information that is stored in said 
first table includes a reference that indicates where said 
values of said collection attribute for said information 
object are stored in said collection storage structure. 

14. A computer-readable medium carrying one or more 
35 sequences of instructions which, when executed by one or 

more processors, cause said one or more processors to store 
an information object in a database system accessible to said 
one or more processors by causing said one or more pro- 
cessors to perform the steps of: 
4Q establishing an information object class that has a collec- 
tion attribute; 

creating said information object as an instance of said 

information object class; 
establishing in said database system a collection storage 
45 structure for said collection attribute; 

creating an information object as an instance of said 

information object class; 
storing attribute information about said information 
object in a first table; 
50 storing values of said collection attribute in said collection 
storage structure; and 
wherein said attribute information that is stored in said 
first table includes a reference that indicates where said 
S5 values of said collection attribute for said information 
object are stored in said collection storage structure. 

15. The computer-readable medium recited in claim 14, 
further comprising sequences of instructions for performing 
the steps of: 

60 establishing a second table in said database system; 

storing a first identifier that identifies said first table and 
a second identifier that identifies said collection storage 
structure; and 

storing within said second table a record that associates 
65 said first identifier with said second identifier. 

16. The computer-readable medium of claim IS, wherein 
said information object class has another collection attribute, 
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and wherein the computer- readable medium further com- 
prises sequences of instructions for performing the step of 
storing within said second table a second record, 
wherein said second record associates said first identifier 
with a third identifier that identifies another collection 
storage structure, wherein said other collection storage 
structure is used to store values that belong to said other 
collection attribute. 

17. The computer-readable medium recited in claim 14, 
further comprising sequences of instructions for performing 
the steps of: 

establishing said collection storage structure in the form 
of a storage table in said database system; 

establishing in said storage table, at least one nested table 15 
portion comprising rows of values of said collection 
attribute associated with said reference; and 

storing a copy of said reference in a column of said 
storage table. 

18. The computer-readable medium recited in claim 14, 20 
wherein said step of establishing an information object class 
that has a collection attribute comprises the step of estab- 
lishing a variable length array as said collection attribute of 
said information object class. 

19. The computer-readable medium recited in claim 18, 25 
further comprising sequences of instructions for performing 
the steps of: 

when said variable length array is defined having fixed- 
length elements: 

computing a maximum size value representing an 30 
amount of storage space required for an instance of 
said variable length array; and 

storing said variable length array in a database column 
when said maximum size value is equal to or less 
than a pre-defined maximum database column size 35 
value. 

20. The computer-readable medium recited in claim 19, 
further comprising sequences of instructions for performing 
the step of storing said variable length array in a large object 
structure when said maximum size value is greater than said 40 
maximum database column size value. 


21. The computer-readable medium recited in claim 18, 
further comprising sequences of instructions for performing 
the step of: " 

when said variable length array is defined having 
variable-length elements, storing said variable length 
array in an index-organized table. 

22. The computer-readable medium recited in claim 21, 
further comprising sequences of instructions for performing 
the step of storing, in a node of said index-organized table, 
an identifier of said variable length array, an element order 
value indicating an ordinal position within said variable 
length array of an element of said variable length array, and 
a value of said element. 

23. The computer-readable medium recited in claim 14, 
further comprising sequences of instructions for performing 
the steps of: 

establishing said collection storage structure as an index 

organized table; and 
storing, in a leaf node of said index organized table, a 

value of said collection attribute. 

24. The computer-readable medium recited in claim 14, 
further comprising sequences of instructions for performing 
the steps of: 

retrieving said information object by carrying out the 
steps of; 

when said information object has at least one collection 
attribute: 

retrieving said reference to said collection storage 
structure; and 

retrieving a value of an element of said collection attribute 
and delivering said value to an external process only 
when said element is accessed by said external process. 

25. The computer-readable medium recited in claim 24, 
further comprising sequences of instructions for performing 
the steps of: 

retrieving said information object and all values of each 

attribute thereof when said 
information object has no collection attribute. 
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